home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / rfc / rfcxxxx / rfc1715 < prev    next >
Text File  |  1995-07-25  |  7KB  |  228 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         C. Huitema
  8. Request for Comments:  1715                                        INRIA
  9. Category: Informational                                    November 1994
  10.  
  11.  
  12.              The H Ratio for Address Assignment Efficiency
  13.  
  14. Status of this Memo
  15.  
  16.    This memo provides information for the Internet community.  This memo
  17.    does not specify an Internet standard of any kind.  Distribution of
  18.    this memo is unlimited.
  19.  
  20. Abstract
  21.  
  22.    This document was submitted to the IETF IPng area in response to RFC
  23.    1550.  Publication of this document does not imply acceptance by the
  24.    IPng area of any ideas expressed within.  Comments should be
  25.    submitted to the author and/or the sipp@sunroof.eng.sun.com mailing
  26.    list.
  27.  
  28. Table of Contents
  29.  
  30.    1.   Efficiency of address assignment . . . . . . . . . . . . . . 1
  31.    2.   Estimating reasonable values for the ratio H . . . . . . . . 2
  32.    3.   Evaluating proposed address plans. . . . . . . . . . . . . . 3
  33.    4.   Security Considerations . . . . . . . . . . . . . . . . . .  4
  34.    5.   Author's Address . . . . . . . . . . . . . . . . . . . . . . 4
  35.  
  36. 1. Efficiency of address assignment
  37.  
  38.    A substantial part of the "IPng" debate was devoted to the choice of
  39.    an address size. A recurring concept was that of "assignment
  40.    efficiency", which most people involved in the discussion expressed
  41.    as a the ratio of the effective number of systems in the network over
  42.    the theoretical maximum. For example, the 32 bits IP addressing plan
  43.    could in theory number over 7 billions of systems; as of today, we
  44.    have about 3.5 millions of addresses reported in the DNS, which would
  45.    translate in an efficiency of 0.05%.
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Huitema                                                         [Page 1]
  59.  
  60. RFC 1715                        H Ratio                    November 1994
  61.  
  62.  
  63.    But this classic evaluation is misleading, as it does not take into
  64.    account the number of hierarchical elements. IP addresses, for
  65.    example, have at least three degrees of hierarchy: network, subnet
  66.    and host.  In order to remove these dependencies, I propose to use a
  67.    logarithmic scale for the efficiency ratio:
  68.  
  69.                              log (number of objects)
  70.                          H = -----------------------
  71.                                   available bits
  72.  
  73.    The ratio H is not too dependent of the number of hierarchical
  74.    levels. Suppose for example that we have the choice between two
  75.    levels, encoded on 8 bits each, and one single level, encoded in 16
  76.    bits. We will obtain the same efficiency if we allocate in average
  77.    100 elements at each 8 bits level, or simply 10000 elements in the
  78.    single 16 bits level.
  79.  
  80.    Note that I use base 10 logs in what follows, because they are easier
  81.    to compute mentally. When it comes to large numbers, people tend to
  82.    use "powers of 10", as in "IPng should be capable of numbering 1 E+15
  83.    systems". It follows from this choice of units that H varies between
  84.    0 and a theoretical maximum of 0.30103 (log base 10 of 2).
  85.  
  86. 2. Estimating reasonable values for the ratio H:
  87.  
  88.    Indeed, we don't expect to achieve a ratio of 0.3 in practice, and
  89.    the interesting question is to assert the values which can be
  90.    reasonably expected. We can try to evaluate them from existing
  91.    numbering plans. What is especially interesting is to consider the
  92.    moment where the plans broke, i.e. when people were forced to add
  93.    digits to phone number, or to add bits to computer addresses. I have
  94.    a number of such figures handy, e.g.:
  95.  
  96.    * Adding one digit to all French telephone numbers, moving from 8
  97.      digits to 9, when the number of phones reached a threshold of 1.0
  98.      E+7. The log value is 7, the number of bits was about 27 (1 decimal
  99.      digit is about 3.3 bits). The ratio is thus 0.26
  100.  
  101.    * Expending the number of areas in the US telephone system, making it
  102.      effectively 10 digits long, for about 1.0 E+8 subscribers. The log
  103.      value is 8, the number of bits is 33, the ratio is about 0.24
  104.  
  105.    * Expending the size of the Internet addresses, from 32 bits to
  106.      something else. There are currently about 3 million hosts on the
  107.      net, for 32 bits. The log of 3.E6 is about 6.5; this gives a ratio
  108.      of 0.20. Indeed, we believe that 32 bits will still be enough for
  109.      some years, e.g. to multiply the number of hosts by 10, in which
  110.      case the ratio would climb to 0.23
  111.  
  112.  
  113.  
  114. Huitema                                                         [Page 2]
  115.  
  116. RFC 1715                        H Ratio                    November 1994
  117.  
  118.  
  119.    * Expending the size of the SITA 7 characters address. According to
  120.      their documentation, they have about 64000 addressed points in
  121.      their network, scattered in 1200 cities, 180 countries. An upper
  122.      case character provides about 5 bits of addressing, which results
  123.      in an efficiency of 0.14. This is an extreme case, as SITA uses
  124.      fixed length tokens in its hierarchy.
  125.  
  126.    * The globally-connected physics/space science DECnet (Phase IV)
  127.      stopped growing at about 15K nodes (i.e. new nodes were hidden)
  128.      which in a 16 bit space gives a ratio of 0.26
  129.  
  130.    * There are about 200 million IEEE 802 nodes in a 46 bit space, which
  131.      gives a ratio of 0.18. That number space, however, is not
  132.      saturated.
  133.  
  134.    From these examples, we can assert that the efficiency ratio usually
  135.    lies between 0.14 and 0.26.
  136.  
  137. 3. Evaluating proposed address plans
  138.  
  139.    Using a reverse computation, we get the following population counts
  140.    in the network:
  141.  
  142.                     Pessimistic (0.14)     Optimistic (0.26)
  143.  
  144.       32 bits             3 E+4 (!)           2 E+8
  145.       64 bits             9 E+8               4 E+16
  146.       80 bits           1.6 E+11            2.6 E+27
  147.      128 bits             8 E+17              2 E+33
  148.  
  149.    I guess that the figure explains well why some feel that 64 bits is
  150.    "not enough" while other feel it is "sufficient by a large margin":
  151.    depending of the assignment efficiency, we are either well below the
  152.    target or well above. But there is no question, in my view, that 128
  153.    bits is "more than enough". Even if we presume the lowest efficiency,
  154.    we are still way above the hyperbolic estimate of 1.E+15 Internet
  155.    hosts.
  156.  
  157.    It is also interesting to note that if we devote 80 bits to the
  158.    "network" and use 48 bits for "server less autoconfiguration", we can
  159.    number more that E.11 networks in the pessimistic case - it would
  160.    only take an efficiency of 0.15 to reach the E+12 networks hyperbole.
  161.  
  162.    I guess this explains well why I feel that 128 bits is entirely safe
  163.    for the next 30 year. The level of constraints that we will have to
  164.    incorporate in the address assignment appears very much in line with
  165.    what we know how to do, today.
  166.  
  167.  
  168.  
  169.  
  170. Huitema                                                         [Page 3]
  171.  
  172. RFC 1715                        H Ratio                    November 1994
  173.  
  174.  
  175. 4.  Security Considerations
  176.  
  177.    Security issues are not discussed in this memo.
  178.  
  179. 5. Author's Address
  180.  
  181.    Christian Huitema
  182.    INRIA, Sophia-Antipolis
  183.    2004 Route des Lucioles
  184.    BP 109
  185.    F-06561 Valbonne Cedex
  186.    France
  187.  
  188.    Phone: +33 93 65 77 15
  189.    EMail: Christian.Huitema@MIRSA.INRIA.FR
  190.  
  191.  
  192.  
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Huitema                                                         [Page 4]
  227.  
  228.